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This  is  the  second  monthly  progress  report  for  the  Multispectral  High  Fidelity  RADAR 
Scene  Generator  SBIR  (Phase  I),  Contract  #  N68335-99-C-0126. 

1.0  Work  Smnmary 

Work  was  done  between  Mar.  12  and  Apr.  12  to  define  the  various  process  blocks  within 
the  RADAR  Scene  Generator  (RSG).  The  RSG  overall  process  was  separated  into  components 
and  each  component  was  broken  down  further  into  its  corresponding  elements  until  the  basic 
physical  phenomena  were  reached.  The  best  description  for  the  interconnections  lends  itself 
well  to  gr£^hical  representation;  hence,  several  figures  have  been  presented  to  describe  how 
each  individual  contribution  fits  into  the  overall  RSG. 

2.0  Schedule 

As  anticipated  in  the  proposal,  a  conplete  block  diagram  of  all  the  processes  involved 
in  RADAR  scene  generation  has  been  created.  This  2"^  progress  report  has  been  submitted  late 
due  to  unavoidable  circumstances  that  affected  the  principal  investigator’s  schedule.  Progress 
reporting  will  resume  on  schedule  with  the  next  progress  report. 

There  is  1  topic  (process  metrics)  that  was  expected  to  be  addressed  during  this 
reporting  period,  but  has  been  postponed  due  to  an  unexpectedly  large  work  effort  this  month. 
The  next  month’s  work  is  anticipated  to  be  light,  and  reporting  will  address  leftover  topics 
from  this  month’s  progress  as  well. 

3.0  Studies 

3.1  Liput  information  for  the  Radar  Scene  Generator  ^SG) 

The  first  step  was  to  consider  the  universe  of  inputs  that  might  be  expected  within  the 
RADAR  scene.  These  inputs  can  be  classified  in  various  categories: 
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a)  RADAR  environment  inputs: 

Meteorological  inputs: 

Weather  -  Rain,  snow,  sleet,  hail,  fog 

Wind  --  Velocity,  turbulence 

Propagation  Effects: 

Multipath,  ducting,  diffraction,  refraction 

Earth  Clutter  contributors: 

Land,  Sea  --  Distributed  and  discrete  elements 

Surface  characteristics  -  terrain  roughness,  vegetation,  sea  state 

Airborne  clutter  contributors: 

Birds,  insects,  airborne  dust 

b)  Target  inputs: 

Known  objects: 

Projectiles  --  Ballistic,  powered,  guided 
Aircraft  —  fixed  &  rotary  wing,  un-powered 
Surface  vehicles  --  land  &  sea  based 

Unknown  objects: 

Angels  ~  Any  unknown  object  that  provides  discrete  RADAR  echoes,  is 
visible  to  the  main  beam,  but  is  not  described  above. 

c)  EMI: 

All  other  signals  that  provide  responses  in  the  RADAR  receiver.  In  certain  RADARs, 
jammers  can  be  modeled  in  this  category.  Inadvertent  industrial  electro-magnetic 
interference  with  the  RADAR  can  also  fall  into  this  category  once  it  has  been 
characterized. 

The  anticipated  spectral  content  and  ERP  work  well  as  descriptions  for  this  class  of 
inputs. 

d)  Temporal  Dynamics: 

That  describe  the  time  vs.  position  behavior  for  all  of  the  above.  Typically,  these  are 
models  that  describe  flight  paths  for  the  target  category  in  the  classical  sense. 
However,  bird  flight  paths,  migration  seasons  and  temporal  insect  behavior  are  some  of 
the  other  issues  that  are  governed  by  these  models,  as  well  as  factory  operating  hours 
that  might  tell  of  concentrated  vehicle  traffic  or  in  some  cases,  tell  of  most  likely  EMI 
sources. 
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e)  RADAR  parameters  -  Most  modem  RADARs  are  able  to  change  all  these  parameters  in 
real  time  fashion: 

Antenna  beam  patterns  (sum,  delta  &  other  auxiliary  channels) 

Waveform(s)  -  Operating  frequency 

Pulse  Repetition  Frequency 

Data  collection  gate  position 

Antenna  Beam  position  (azimuth  &  elevation) 

Receive  STC  contour 

Dynamic  Gain  Control  setting  (AGC,  RGC  etc.) 

3.2  Mapping  these  input  entities  onto  the  RADAR  grid 

Now  that  we  have  defined  a  palette  of  objects  that  will  be  processed  by  the  RADAR, 
we  have  to  be  able  to  choose  and  place  what  we  need  on  the  RADAR’S  measurement  grid. 

3.2.1  RADAR  environment  components 

The  RADAR  environment  components  described  in  “a”  will  be  placed  in  Az/El/Range 
space.  Because  of  their  distributed  nature,  these  components  require  containment.  All  the 
components  except  for  earth  clutter  are  localized  and  therefore  can  be  described  by  a 
boundary. 

A  convenient  description  for  containment  was  required  for  the  distributed  clutter.  An 
easy  to  describe  3  dimensional  elliptical  shape  (3DES)  was  considered  as  the  building  block  by 
which  all  distributed  clutter  could  be  constmcted. 

The  RSG  operator  will  be  required  to  constmct  these  3DES  entities  and  place  them  on  a 
cartesian  coordinate  grid  corresponding  to  the  actual  position  of  the  phenomena.  A  GUI 
program  is  anticipated  to  be  the  engine  for  RADAR  Scene  definition,  drawing  form  a  DTED 
map  for  reference.  Details  for  this  interface  are  TBD. 
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Figure  1  -  Pictorial  Representation  of  3-D  Elliptical  Shape  (3DES) 


3.2.1.1  Limiting  extent  of  clutter  components 

Figure  1  pictorially  describes  the  3DES  entity  and  the  associated  inputs  and  outputs. 
The  3DES  entity  is  the  vehicle  by  which  distributed  RADAR  returns  get  put  in  the  RADAR’S 
field  of  view.  The  inputs  describe  the  entity  shape,  size,  distance,  orientation  and  velocity 
with  respect  to  the  RADAR  location,  while  Ae  outputs  describe  the  reflection  amplitude  and 
spectral  characteristics  of  the  RADAR  cells  within  the  entity. 

3.2.1.1.1  Functional  definition  for  3DES  module 

The  following  will  be  the  inputs  to  the  3DES  synthesis: 

a)  type  of  entity  [airborne  clutter:  bird,  insects,  dust  etc,  weather:  rain,  snow,  etc] 

b)  position  (radar  relative  [x/y/z]) 

c)  size  of  entity  along  3  axes  of  ellipse  [m] 

d)  mean  velocity  [m/sec] 

e)  density  [will  be  type  dependent] 

f)  aspect  angle  [wrt  Radar  line  of  sight] 

g)  distribution  type  [probably  will  related  to  ‘a’ 
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Outputs  from  this  module  are: 

a)  Clutter  amplitude  for  each  of  (n)  Radar  channels,  where  (n)  is  RADAR  specific 

b)  Spectral  table  that  will  be  used  for  each  cell  within  3DES  entity 

The  entity  description  is  an  essential  element  of  all  RSG  clutter  signal  synthesis. 

3.2. 1.2  Considering  Propagation  effects 

This  module  will  address  the  propagation  effects  that  are  visible  to  the  RADAR.  At  the 
lower  elevation  angles  closest  to  the  earth,  propagation  is  dominated  by  terrain  features.  The 
terrain  is  largely  responsible  for  introducing  multipath  and  diffraction  into  the  RF  signal 
environment.  As  the  elevation  angle  increases,  the  propagation  is  increasingly  influenced  by 
meteorological  phenomena  such  as  clouds,  fog,  inversion  layers,  weather  fronts  etc... which  in 
turn  describe  the  refractive  environment  seen  by  the  RF  signals.  This  underscores  the 
importance  of  correct  meteorological  inputs  as  well  as  accurate  models  of  terrain  reflection 
coefficients  and  accurate  assessments  of  dielectric  constant  variation  in  air  as  a  function  of 
temperature,  humidity  and  barometric  pressure. 

A  part  of  the  problem  associated  with  obtaining  accurate  meteorological  information  is 
that  the  local  weather  conditions  are  often  monitored  by  a  weather  RADAR.  The  elevation 
position  as  seen  by  the  weather  RADAR  is  tainted  by  the  same  propagation  phenomena  that  the 
RSG  is  trying  to  characterize,  hence  there  is  some  error  built  into  Ae  RSG  ou^ut  regardless  of 
the  accuracy  of  the  propagation  model. 

Once  the  correct  interfaces  have  been  established  between  all  the  weather  and  earth 
boundaries,  use  of  the  Parabolic  Wave  Equation  (PWE)  is  planned.  The  PWE  output  will  be 
expressed  in  RADAR  terms;  namely  apparent  attenuation  and  phase  shift  as  a  function  of  the 
cartesian  axes  X/Y/Z.  Examples  of  such  output  have  been  provided  for  low  altitude  ducting 
phenomena  due  to  atmospheric  inversion  in  IEEE  Transactions  on  Antennas  and  Propagation 
Vol.  45  No.  9  ppl340  -  1347. 

This  information  will  be  applied  to  all  entities  placed  in  a  RADAR  relative  cartesian 
coordinate  grid,  before  conversion  to  RADAR  relative  Az/El/Range  coordinates  and  beam 
convolution.  The  PWE  described  effects  are  placed  at  this  basic  level  to  ensure  fidelity  of  the 
anticipated  effects. 

One  of  the  shortcomings  of  this  ^proach  is  that  the  propagation  effects  in  the  RSG 
scene  will  be  difficult  to  vary  as  a  function  of  time.  The  easy  way  to  circumvent  this  problem 
is  to  construct  separate  scenes,  each  with  incrementally  different  weather  conditions.  This 
incremental  technique  can  work  well  for  non-real  time  RSG  operation,  but  might  prove 
cumbersome  in  real-time  RADAR  interfaces. 
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3.2.1.2.1  Requirements  for  ^^propagation  effects**  module 

The  GUI  user  interface  described  in  3.2. 1  can  be  used  to  place  the  weather  phenomena 
in  the  RADAR  scene.  For  an  actual  RADAR  site  evaluation,  the  goal  will  be  to  receive 
weather  information  in  some  predetermined  file  format  directly  from  the  local  weather  station 
and  apply  the  pertinent  information  to  the  RADAR  scene. 

As  a  consequence  of  placing  weather  on  the  scene,  the  RADAR  relative  cartesian 
coordinate  grid  will  be  filled  with  the  various  weather  forms. 

The  inputs  for  this  module  will  be: 

a)  RADAR  relative  X/Y/Z  grid  with  weather  phenomena  (resolution  TBD) 

b)  Various  tables  for  reflection  coefficients  of  land/sea.  Initially,  a  set  of  default 
(textbook)  values  may  be  used,  then  updated  as  data  becomes  available. 

c)  Various  tables  with  dielectric  constants  for  air  as  a  function  of  temperature 
humidity  and  barometric  pressure.  Once  again,  start  with  default  tables,  update 
based  on  data  availability. 

d)  Access  to  DTED  m^  for  terrain  elevation  information  as  well  as  surface 
roughness  characteristics 

Outputs  will  be: 

a)  Effective  attenuation  and  phase  shift  as  seen  from  the  phase  center  of  the 
RADAR  antenna  placed  on  the  RADAR  relative  cartesian  coordinate  grid. 

Once  again,  recall  that  this  information  will  be  applied  to  all  entities  that  can  provide  a 
RADAR  echo. 


3.2.1.3  RSG  clutter  generation 

The  business  of  RSG  clutter  signal  synthesis  process  can  be  described  as  follows: 

a)  A  class  of  clutter  gets  selected  for  consideration  in  the  RADAR  scene...  This 
can  be  any  sort  of  clutter  discussed  earlier.  The  effective  RCS  and  spectral 
characteristics  of  the  object  are  available  through  the  research  literature. 

For  the  special  case  of  ground  clutter,  the  grazing  angle  is  to  be  computed  for 
each  “plate”  defined  by  adjacent  elevation  measurements,  and  at  the  DTED  map 
resolution.  Then,  the  impropriate  clutter  backscatter  coefficient  is  k) 

each  plate.  This  coefficient  is  typically  dependent  on  the  grazing  angle  and 
ground  coverage  (wet,  dry,  snow,  vegetation,  etc...) 

b)  The  pertinent  weather  wind  (or  turbulence)  induced  modulation  is  computed  and 
applied  to  the  spectral  components  of  the  corresponding  to  that  specific  class  of 
clutter. 
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c)  The  3DES  entity  boundaries  as  described  above  limit  the  size  of  the  cell(s)  as 
they  get  placed  by  the  operator  on  a  RADAR  relative  cartesian  coordinate  grid. 

d)  When  all  the  entities  have  been  placed  on  the  radar  relative  cartesian  coordinate 
grid,  the  antenna  beam  pattern  gets  s^piied  to  the  composite  clutter  at  each 
Az/El/Range  cell.  This  means  that  die  antenna  sidelobe  contributions  from 
other  azimuth  and  elevation  angles  folded  into  the  t^parent  RADAR  echo  put 
out  by  the  RSG.  This  operation  often  referred  to  as  “beam  convolution”,  by 
necessity  is  performed  in  RADAR  relative  Az/El/Range  space. 

e)  The  echo  amplitude  is  weighted  as  a  function  of  range  as  governed  by  the 
RADAR  range  equation  before  being  presented  to  the  RADAR  (model). 

3.2.1.4  Functional  definition  for  beam  convolution  module 

The  beam  convolution  module  will  accept  the  following  inputs: 

a)  X/Y/Z  cartesian  coordinate  grid  at  the  DTED  mtp  resolution,  filled  with  3DES 
entities  of  the  selected  clutter. 

b)  RADAR  parameters : 

Azimuth  beamwidth 
Elevation  beamwidth 
Search  mode  range  cell  size(s) 

Search  scan  sector 

Antenna  principal  plane  and  off-principal  plane  sidelobe  levels 

Outputs  from  the  Beam  convolution  module  are: 

Convolved  clutter  amplitude  and  velocity  spectra  at  double  the  Az/El/Range 
resolution  within  the  RADAR  coverage.  Recall  that  returns  have  to  be 
computed  at  twice  the  resolution  so  that  at  “run-time”  the  return  data  can  be 
interpolated  for  precision  tracks  that  require  beam  positions  between  the 
quantization  described  by  the  RADAR  Az/El/Range  grid. 

3.2.1.5  Clutter  component  generation 

The  following  several  figures  show  the  path  that  information  has  to  take  before  it  finds 
its  way  to  the  RADAR  model  that  the  RSG  is  required  to  test: 
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3.2.1.5.1  Weather  Clutter  generation 
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F^ure  2  -  Weather  clutter  synthesis  process. 

Figure  2  pictorially  describes  the  process  for  synthesizing  weather  clutter.  Each 
“circle  X”  represents  a  modulation  process,  where  details  have  not  been  completely  ironed  out, 
but  are  different  for  each  block.  This  flow  grtq)h  is  intended  to  show  the  process  by  which  all 
the  inputs  discussed  in  para  3.1  contribute  to  the  eventual  RSG  output. 

The  small  font  description  in  the  vicinity  of  each  “circle  X”  describes  the  attribute  that 
the  modulation  will  be  addressing. 

Weather  clutter  generator  module 


Weather  Clutter  -  A  range/Az/El  grid  in  75/1/1  [mtr/deg/deg]  increments  of  clutter 

backscatter  coefficient  and  velocity  spectrum  [m/sec].  Inputs  to 
this  module  are: 

a)  type  of  weather  (rain,  snow,  htdl,  sleet,  fog,  turbulence) 

b)  radar  frequency 

c)  intensity  of  weather 

Grid  size  is  +45,  -45  [deg]  azimuth,  -10,  +45  [deg]  elevation 
and  0,  +300  mtr.  Range. 

Spectral  change  as  a  function  of  elevation  must  be  considered  (as  the  Radar  beam  looks 
up,  into  various  precipitation). 

C)uq)uts  from  this  module  are: 

c)  Clutter  amplitude  for  each  of  (six)  Radar  channels 

d)  Spectral  table  that  will  be  used  for  each  cell  within  entity 
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3.2.1.5.2  Earth  Clutter  generation 

The  Earth  clutter  generator  has  dual  function.  The  first  function  is  to  provide  a  mask 
angle  that  the  RADAR  can  use  to  place  its  search  beam  in  elevation.  This  information  has  to 
be  computed  in  1  of  2  ways  (operator  selectable): 

a)  By  using  the  DTED  m^  information  and  the  RADAR  location  to  derive  a  line- 
of-sight  clutter  profile  (called  the  optical  mask  angle).  This  information  is  used 
by  the  operator  to  place  the  elevation  of  the  RADAR  search  beam. 

b)  By  providing  an  elevation  angle  for  each  increment  of  azimuth  where  the  earth 
clutter  backscatter  falls  below  an  operator  determined  threshold.  This  is  the 
radiometric  mask  angle.  This  information  can  be  compared  to  the  RADAR 
derived  radiometric  mask  angle  when  this  mode  is  available  in  the  RADAR 
under  test. 

Figure  3  -  Pictorial  description  of  Earth  clutter  generation 


Radiometric  mask  is  based  on  RF  backscatter  threshold 


There  are  situations  where  the  weather  clutter  interacts  with  the  earth  clutter 
backscatter.  One  such  example  is  when  rain  falls  at  sea.  In  this  situation,  the  physical  shape 
of  the  raindrop  “bounce”  on  water  produces  extreme  reflections  that  are  frequency  sensitive. 
This  phenomenon  happens  not  only  at  sea,  but  any  time  there  is  a  body  of  water.  There  will 
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have  to  be  some  probabilistic  assumptions  made  to  accommodate  this  sort  of  behavior  on  land 
when  puddles  form. 

As  can  be  seen  in  figure  3,  there  is  an  opportunity  to  limit  the  clutter  extent  as  with  all 
the  other  forms  of  distributed  clutter.  This  has  been  provided  so  that  clutter  rejection  (or 
detection)  algorithms  can  be  developed  with  the  aid  of  the  RSG. 

The  resulting  entities  are  placed  on  the  RADAR  relative  cartesian  grid,  and  then 
transformed  to  the  RADAR  Az/El/Range  grid  before  “beam  convolution”.  The  range  equation 
governed  amplitude  scaling  is  then  applied  as  a  matter  of  course. 

3.2.1. 5.3  Earth  clutter  discretes 

To  accommodate  the  situation  where  large  stationary  discrete  objects  exist  on  the 
surface  of  the  earth,  facility  has  been  provided  in  the  RSG  clutter  generator.  Figure  4  shows 
the  process  pictorially. 

The  operator  will  be  able  to  place  discrete  objects  of  known  cross-section  anywhere  on 
the  DTED  map  surface,  or  for  that  matter,  anywhere  in  RADAR  relative  cartesian  coordinate 
space.  Typically  this  sort  of  clutter  description  is  used  to  characterize  urban  environments 
where  buildings  might  be  in  the  RADAR’S  field  of  view,  or  at  sea  where  anchored  ships  may 
be  visible  to  the  RADAR. 


Once  again,  this  process  is  similar  to  the  others  presented  above,  and  is  described 
pictorially  in  figure  4. 

Earth  Clutter  generator  deflnition 

Ground  clutter  -  A  range/ Az/El  grid  in  TBD  [mtr/deg/deg]  increments  of  clutter 
backscatter  coefficient  given  fixed  point  and  direction  of  view  on 
a  DTED  map.  Other  inputs  to  this  module  are: 
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a)  Radar  frequency 

b)  Terrain  roughness 

c)  Sea  state  (if  ^plicable) 

d)  Wind  velocity 

Discrete  clutter  entities  will  be  able  to  be  entered  into  the  clutter  map  at  operator 
chosen  random  points  in  the  range/Az/El  grid.  Each  discrete  entity  will  have 
associated: 

a)  backscatter  coefficient 

b)  elevation  extent 

Grid  size  Is  TBD. 

Outputs  from  this  module  are: 

a)  Range/az/el  grid  filled  with  clutter  amplitudes  for  each  of 
(5  ?)  Radar  channels 

b)  Spectral  table  that  will  be  used  for  each  cell 

3.2.1.5.4  Airborne  clutter 

Distributed  airborne  clutter  is  generated  through  the  same  process  as  all  other 
distributed  clutter  and  is  graphically  described  in  figure  5. 

Some  of  the  inputs  along  the  generation  process  are  mutually  exclusive  with  the  class  of 
clutter.  For  example,  when  there  is  significant  turbulence,  the  likelihood  of  bird  flocks  and 
insect  clouds  is  rather  remote.  In  this  situation,  single  bird  models  will  have  to  be  used,  and 
insect  clouds  will  have  to  be  excluded. 

A  large  portion  of  the  scene  validity  will  depend  on  the  operator.  The  RSG  code  will 
have  warning  or  advisory  notices  built  in  for  unlikely  combinations  of  clutter  selection,  but  the 
operator  will  be  given  discretion  to  override  the  notices. 

Airborne  clutter  generator  definition 

Sky  Clutter  -  this  form  of  clutter  will  be  described  by  3  dimensional  elliptical 

entities.  The  operator  will  be  able  to  place  these  entities 
anywhere  on  the  range/Az/El  grid.  The  following  will  be  the 
inputs  to  the  entity  synthesis: 

h)  type  of  entity  [bird,  insects,  dust  etc] 

i)  position  (radar  relative  [range/az/el]  or  [x/y/z]) 

j)  size  of  entity  along  3  axes  of  ellipse  [m] 

k)  mean  velocity  [m/sec] 

l)  density  [will  be  type  dependent] 

m)  aspect  angle  [wrt  Radar  line  of  sight] 

n)  distribution  type  [probably  related  to  ‘a’] 
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Outputs  from  this  module  are: 


e)  Clutter  amplitude  for  each  of  (six)  Radar  channels 

f)  Spectral  table  that  will  be  used  for  each  cell  within  entity 


3.2.2  Target  Components 

The  target  description  covers  the  gamut  of  moving  discrete  objects.  Because  of  the 
flexibility  of  the  target  description  (described  in  the  first  progress  report),  this  file  can  also 
include  EMI,  jammers  and  “angels”  which  are  defined  as  all  those  objects  that  appear  as 
targets  on  the  RADAR  di^lay,  but  the  origins  of  which  are  not  understood. 

Each  target  will  require  an  associated  behavior  model.  This  means  that  a  flight  path 
will  have  to  be  generated.  The  flight  path  is  fairly  well  determined  for  ballistic  projectiles  such 
as  artillery  and  mortar  shells  and  rockets,  but  airplane  and  helicopter  flight  paths  will  have  to 
be  generated  after  a  dialogue  with  the  RSG  operator  (for  specific  targets),  or  chosen  from  a 
default  set  of  typical  behavior  for  various  classes  of  airborne  targets. 

For  EMI  and  jammer  behavior  operator  dialogue  will  be  necessary  as  well.  An  all 
inclusive  target  generator  module  will  be  required  to  generate  all  targets. 

The  target  generator  module  will  have  to  allow  the  operator  to  generate  a  flight  path 
using  a  set  of  basic  lines  and  curvps.  At  the  ends  of  each  segment  used  to  construct  the  flight 
path,  the  velocity  of  the  aircraft  will  have  to  be  known. 
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For  non-guided  ballistic  trajectories,  the  Modiiied  Point  Mass  Model  which  was 
developed  by  the  US  Army’s  Ballistics  Research  Lab,  In  Aberdeen,  MD  is  routinely  used  at 
Malibu  Research  and  works  well. 

3.2.2.1Requiremeiits  for  the  target  generator  module 

Delicious  parameters...  the  following  in  Radar  relative  coordinates  as  a  function  of  time  in 
TBDl  msec  increments  (TBD2  msec  if  the  rdot  is  >  TBD3  m/sec)  will  be  required: 

a)  azimuth  [deg],  elevation  [deg],  range  [m] 

b)  rdot  [m/sec], 

c)  elev.  angle  of  projectile  wit  local  horizontal  [deg] 

d)  aspect  angle  of  projectile  wrt  line  of  sight  to  Radar  [deg] 

TBDl  above  is  related  to  the  measurement  time  of  the  RADAR.  The  update  rate  will 
have  to  be  faster  than  the  time  between  2  subsequent  RADAR  measurements. 

TBD3  &  TBD3  have  to  do  with  significant  target  motion  within  a  coherent 
measurement  interval  (called  a  dwell).  If  the  target  moves  significantly  during  a  dwell,  then 
the  range  position  and  Doppler  frequency  measurement  precision  of  f  the  RADAR  may  be 
compromised  depending  on  the  sophistication  of  the  signal  processing  in  the  RADAR.  These 
effects  have  to  be  properly  modeled  by  representing  the  target  as  multiple  “sub-targets”  in 
adjacent  range  bins  and  adjusting  the  amplitude  and  phase  of  each  of  the  sub-target  during  the 
dwell. 


Further,  if  the  target  velocity  exceeds  TBD4  then  the  time  sidelobes  associated  with 
coherent  detection  of  a  phase  or  frequency  coded  pulse  rise  to  unacceptable  levels,  and  the 
range  resolution  of  the  RADAR  is  compromised.  Once  again  the  “sub-target”  j^proach  is 
used  here. 

Inputs  to  this  module  will  be  we^on  type,  firing  geometry  and  pertinent  meteorological 
information  (such  as  wind  velocity). 

3.2.2.2  RCS  Generation  requirements 

A  set  of  RCS  tables  and  spectral  tables  will  be  required  as  well  to  present  the  target  in 
RADAR  terms.  RCS  information  consists  of: 

a)  The  projectile  RCS  when  the  transmitter  and  receiver  have  identical  electrical 
polarization  axes  that  are  perpendicular  to  the  radial  dimension  of  the  projectile 
(often  called  H-H  response) 

b)  The  projectile  RCS  when  the  transmitter  and  receiver  have  identical  electrical 
polarization  axes  that  are  perpendicular  to  the  axial  dimension  of  the  projectile 
(often  called  V-V  response) 

c)  Relative  phase  angle  between  the  H-H  response  and  the  V-V  response  as  a 
function  of  aspect  angle  (often  called  the  H-V  phase). 

d)  A  reference  value  [dBsm]  that  can  be  ^plied  to  the  data. 
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This  sort  of  RF  characterization  is  computed  using  the  US  Army’s  “DICE”  model  or 
equivalently,  using  an  Ohio  State  University  Electroscience  Laboratory  software  product  called 
“Radar  Cross  Section  -  Basic  Scattering  Code”  (RCSBSC  for  short).  Malibu  Research  is  in 
possession  of  RCSBSC  version  2. 

This  RCSBSC  vers.  2  code  is  routinely  used  at  Malibu  research  to  estimate  cross 
sections  for  various  projectiles.  Comparison  to  measured  data  for  specific  projectiles  has 
shown  remarkable  agreement. 

Inputs  to  the  RCSBSC  code  are: 

a)  Definition  of  the  shape  of  the  object  under  consideration.  This  is  done  within 
the  program  using  a  basis  set  of  solid  geometric  shapes. 

b)  RF  frequency  of  operation. 

Target  generation  is  pictorially  described  in  figure  6 

JAMMERS 


Figure  6  -  Target  Generator  flow 

3.2.3  RADAR  (non-^oherent)  Interference  module 

The  remaining  component  of  the  RSG  is  the  EMI  (&  ECM)  module.  Here,  the  non¬ 
coherent  interference  will  be  treated  as  bandlimited  noise  sources.  Once  again  these  will  be 
placed  on  the  cartesian  RADAR  grid  by  the  operator  using  the  GUI  program  discussed  in 
section  3.2.1. 
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The  frequency  contribution  of  each  source  will  be  required.  For  an  existing  RADAR  in 
the  field,  the  interfering  noise  can  be  measured  at  the  site,  whereas  for  potential  RADAR 
designs,  the  spectral  description  of  the  interference  can  be  hypothesized. 

In  either  event,  this  module  will  pick  portion  of  the  spectrum  that  is  consistent  with  the 
RADAR’S  operational  frequency.  Using  this  spectral  shtq)ing,  frequency  colored  noise  time 
samples  will  be  generated  for  each  interference  source.  These  will  be  amplitude  and  phase 
adjusted  based  on  the  propagation  effects  discussed  earlier. 

Most  modem  RADARs  use  multiple  receive  channels  for  anything  from  angle 
measurement  to  interference  rejection.  Each  channel  has  an  associated  phase  shift  relative  to 
the  main  (sum  beam)  channel.  This  will  be  applied  to  the  data,  depending  on  the  relative 
position  of  the  interference  source  with  respect  to  the  antenna  broadside. 

The  antenna  weights  will  be  t^plied  to  the  output  of  the  propagation  effects  (PWE) 
module  to  capture  such  effects  as  multipath  before  implying  the  range  equation  principles  to  the 
waveforms. 

The  flow  for  interference  modeling  in  the  RSG  is  presented  in  figure  7. 
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Scenario  control 


Figure  7  -  Interference  modeling  in  the  RSG 


3.3  The  complete  RADAR  scene 

The  elements  of  the  complete  environment  have  been  described  in  section  3.2  The 
combination  of  all  these  elements  is  what  produces  the  complete  RADAR  scene.  Figure  8 
shows  the  simple  arithmetic  combination  of  all  these  components. 


File:  \MyFiIes\P376\P376-002.RPT;dep 


WEATHER  CLUTTER 
EARTH  CLUTTER 
EARTH  DISCRETES 
AIRBORNE  CLUTTER 
TARGETS 

TTsITFPFFPFMr'P 


RADAR  ^ 
SCENE  ^ 


Figure  8  -  Simple  combination  of  components  to  create  RADAR  scene 


There  are  several  interactive  components  that  allow  the  RSG  scene  to  interact  with  the 
RADAR  (model).  These  (real  time)  iiputs  have  no  bearing  on  the  RADAR  scene,  rather, 
filter  the  portion  of  the  scene  that  the  RADAR  beam  happens  to  be  “looking”  at  before 
application  to  the  RADAR  processor  (model).  The  interactive  components  will  be  reported  at 
the  next  progress  report. 

Metrics  for  the  process  blocks  will  consist  of  measuring  the  outputs  of  the  blocks  in 
some  form  that  will  validate  the  proper  operation  of  the  block.  This  will  be  addressed  in  the 
next  report  as  well. 

4.0  nan  for  next  month 

1.  Report  on  the  leftover  pieces  identified  in  this  report: 

a)  Real  time  inputs  and  their  input  position  in  the  process  of  scene  generation 

b)  Metrics  for  individual  blocks  to  verify  proper  operation 

2.  Create  schematic  for  a  real-time  RSG  implementation.  Describe  components 
used  in  non-real  time  implementation 

5.0  Anticipated  Problems: 

None 
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